This series of articles about Sun OS is by Alexander Newman, executive director of the Sun User Group.
About a year ago a new class of mechanisms appeared on the scene. These protocols were created in order to make exchanging information between applications from different developers easier. The ToolTalk service was one of the first commercial entries, and was later adopted as the messaging service for the common open software environment and is part of the Reference Platform release of the Common Desktop Environment.
ToolTalk arose out of a need to make two basic computational functions easier. At their core (no pun intended) computer applications can interact with each other in one of two ways - they can tell each other what to do (also known as control integration) or they can share data with each other (called data integration). Figuring out a way to get different programs to interact as relative equals has been a problem ever since someone figured out how to make a computer run more than one program simultaneously.
Historically, developers have struggled to overcome the obstacles associated with these two areas. Data integration is easier because in its simplest form, a user would just run the first program, save the output, and use that output as input for the next program, and so on. This concept of inherited data has been born and reborn in a variety of forms from passing named values through environmental vectors to the use of pipes to link two or more running programs.
Like data integration, the more complex issue of control integration has also been evolving. Signals were a simple and early form of control integration. They worked by granting peer programs' OS-like abilities. In essence, signals hard-coded application controls into operating systems by, under certain pre-defined conditions, alerting another program of that condition.
The most successful, and now most common, solution to the issue of application integration is the GUI - short for graphical user interface - in conjunction with a windowing system and a pointing device (like a mouse or tablet). GUIs also facilitate data-sharing through features such as cut-and-paste or drag-and-drop. To the end user, if not strictly to the computer, side-by-side application windows are a form of integration, since they are both visible at the same time, they appear to be "working together."
The most powerful feature of a GUI from a design standpoint is that developers are able to use and extend interface techniques and be fairly sure that end-users will understand those techniques. GUIs have brought a wealth of powerful applications within the technical grasp of the average user, by enabling him or her to master applications which he or she had never seen before. Unfortunately, there's no similar technology for computers. There's nothing which can allow the average application to control another application that it has never seen before.
There are several unsatisfactory solutions to the problems of integration, largely because there are at least nine benchmarks that an acceptable solution must meet:
ToolTalk meets all of these requirements by supporting both object-oriented and procedural messaging. Messages are easy to add to existing applications in order to send and receive information.
Applications can directly talk to ToolTalk or through a service built on top of ToolTalk. Both methods allow applications to communicate with each other and provide end-users with cross-application functionality. An application that talks directly to ToolTalk calls functions from the ToolTalk API library in order to send, receive or create messages. These messages can be used to open or close or even display application windows. Application services use ToolTalk as a mini-network, dedicated solely to communication, and providing users with linking and related capabilities.
In a nutshell, ToolTalk delivers messages created by one application to other applications that have asked to receive them. ToolTalk determines the appropriate recipients and delivers the messages to appropriate applications. In this way ToolTalk allows different, independent applications to communicate with each other without first having direct knowledge of each other.
First, developers of inter-operational applications agree upon a protocol. A protocol is the set of messages exchanged by any group of inter-operating applications. For optimal application autonomy, a protocol should be small and clearly defined. ToolTalk supports two flavors of protocols, procedural protocols (which address messages to processes to make them perform specific tasks) and object protocols (which address messages to application-managed applications).
Since the message protocols specifications include the set of messages and directions for how applications should react when they get messages, the protocols act independent of application version. This is to say, an application can be upgraded, changed or even replaced without affecting the other applications in the group provided the protocols are observed.
ToolTalk keeps track of receiving processes and objects. This means that message senders don't have to be concerned about the locations of objects or processes in any given LAN. A sender can use ToolTalk to address a message, a specific process or any interested process, to an object or an object type - regardless of location.
Events vs operations
ToolTalk divides computer activity into two classes: events andoperations. An event is a newsflash. It simply alerts a process that something has happened by sending a ToolTalk message. The tool that sends the message doesn't care if there is a response. In fact no response is expected. An operation, on the other hand, is an order for action or a request for information. When a tool needs information (or initiates an action) it sends a ToolTalk request. The tool that sent the request expects a response, and also expects to be informed of the request message's status.
Using these message patterns, ToolTalk can determine applicable message recipients. The developer assigns attributes to each message pattern and these attributes determine not only the kind of messages that will be received but, to a lesser extent, their quantity. Once a message is received, ToolTalk compares it to all of the current patterns and finds a match. After matching patterns, the message is examined to determine which application it is addressed to and then is delivered there. Which groups receive messages is determined by the scope of the message - a scope is a boundary of interest, and is the central concept of ToolTalk.
ToolTalk solves certain kinds of problems well. Tool issues, like inter-changeability or automatic invocation, and object issues, like persistence or a widely available distributed object system, are all good uses of ToolTalk. Additionally, ToolTalk is appropriate if your applications need control integration or network transparent events, especially if those events aren't owned by a well-known server (e.g., an X server).
However, ToolTalk does have its shortcomings. First, it's not CORBA-compliant and programs coded to ToolTalk can't be ported to a CORBA-compliant system without major source changes. Second, it's slow. RPC provides high performance, point-to-point invocation of well-known services, and sacrifices only a little flexibility. Last, ToolTalk doesn't transfer large amounts of data well, although future versions of ToolTalk may allow you to bypass the ToolTalk server. The current version copies all message data into the server, making sockets and shared memory a superior method when transferring data from one process to another.
Who's got permission to look at your files?
"Permission" in the Unix world has taken on two related but discrete meanings. There's the technical use of "permissions" - the flags that are set on a file by its owner that indicate what other logins may view, modify, or execute the file. Then there are social permissions: is your boss allowed to read your mail? May your system administrator look at what's in your home directory?
The first use of "permission" is pretty easy to tackle, being a technical issue. The second one proves to be a bumpier ride.
Permissions and chmod
A computer file is what you expect it to be, a container for data. All information on the computer is stored in files. There is a special kind of file called a directory that can contain other files or directories. The easiest way to find out what files are in your local directory (the one you're in) is the ls command. There are additional options that can be invoked after ls that will allow you to find out even more information, "-l" option.
-l
List in long format, giving mode, number of links, owner, size in bytes, and time of last modification for each file. If the file is a special file, the size field will instead contain the major and minor device numbers. If the time of last modification is greater than six months ago, it is shown in the format "month date year;" files modified within six months show "month date time." If the file is a symbolic link, the pathname of the linked-to file is printed preceded by `->'. /usr/5bin/ls will print the group in addition to the owner.
For example, if I wanted to find out everything I could about the file "observer.article," I would type "ls -l observer.article" with the following results:
-rw-rw---- 1 troll 124594 Jun 23 11:01 observer.article
The first field, shown as "-rw-rw----", is the file type and permission bits. The permissions for a file are coded as 10 characters. The first character indicates the type of file. The default is a regular, so nothing special is displayed ("-"). However, if the file is a directory, the first character will be a "d".
The next nine characters are access permission flags. The first (leftmost) three are owner permissions The middle three are group permissions. The last (rightmost) three are world permissions.
The letter "r" indicates read permission (the file can be looked at), the letter "w" indicates write permission (the file can be modified) and the letter "x" grants execute permission (it can be run if it is a script).
In the above example, the permissions for the owner, "troll", are "rw-". That means that troll can read and write the file, but not execute it. The permissions for the file's group are "rw-" also, so anyone in the same group as troll could also read or write the file. The last three permission bits are blank, which means no permission is granted to anyone who is not troll or in the same group as troll.
You can change file permissions by using the chmod command. chmod is simply a matter of adding permission (with the "+" character) and denying or removing permissions (with the "-" character).
Here's an example:
I want to let people in my group, "sug", read and write my file called 'file'. Initially, no one has permission to write my file but me, and the permissions are recorded as -rwx------. So, I type:
~: chmod g+rw file
The "g" in the command line stands for group, the "+" means I'm adding permissions, and the "rw" means read and write. "User" and "World" are abbreviated "u" and "w" respectively. If I decided to deny people outside my group permission to look at this file, I could type "w-rwx" and the all permissions on the file would be revoked.
There is a shorthand way of representing file modes. Each permission category (owner, group and world) is given a number that represents the bits set in the permission field. Below is a table that explains this numbering system. To use this table, you add up the permissions you want. For example, a file that is mode 711 has owner read, write, and execute permissions (400 + 200+100), and group and world both have only execute permission (10+1). Important files should be mode 644 or 600 and think twice before making a file world-writable (mode 666).
+--------------------------------+
¦| Owner Group World¦|
+--------------------------------+
¦| Read 400 40 4 ¦|
¦| Write 200 20 2 ¦|
¦| Execute 100 10 1 ¦|
¦| None 0 0 0 ¦|
+--------------------------------+
You can use this shorthand with chmod as well. Just use the number instead of the symbolic representation. If you want to protect your .login from everyone else, but leave yourself fully enabled (i.e., to -rwx------ or 700), you can type:
~: chmod 700 .login
Your home directory should always be either 700, 711 or 755. Never allow others write permission to your directory. That would allow them to create or destroy your files at will.
Privacy vs. security
One of the unreconcilable differences between users and system administrators is that admins want a system to be secure and users want their files to be private. It's a rare system environment (I believe impossible) that can support both of these conditions fully. Most have some compromise between the two.
There is a general consensus that there's no reason, other than plain rude nosiness, to read mail intended for someone else. Despite system administrators who are afraid that they'll be accountable for any criminal discussions users on their systems are having in e-mail, U.S. law not only doesn't make a system administrator responsible for monitoring mail flowing through a system, the Electronic Communications Privacy Act (ECPA) prohibits it.
The (ECPA) is the primary federal law applicable to the issue of who has access to e-mail and other electronic communications, whether they are "live" or stored. The ECPA is actually two sets of laws. One designed to deal with interception of data transmissions, the other to handle access to stored electronic communications. Unfortunately, there are obvious cases where the boundary between the two gets fuzzy and there has been virtually no precedent from the courts in applying the ECPA and other laws to e-mail.
The basic rule of thumb is treat e-mail like any other personal communication. If you wouldn't open someone else's mail, don't read their e-mail. This applies whether you're an administrator or a user. If the letter/phone call/e-mail isn't for you, hands off unless you have clear permission from at least one of the people involved. And err on the side of privacy. It's almost impossible to get arrested for not reading someone else's e-mail.
While the ECPA isn't structured to protect the e-mail or work-related account of an employee from his or her employer, don't count on that to protect you if you're caught peeking. If you violate the ECPA, you're breaking the law. In fact, not only are you committing a crime, you're committing a civil infraction as well, so you can get sued in civil court. Once again, if you're in any doubt about whether or not it's all right to read someone else's files - don't.
The issues of privacy, security and legality intersect in a great big mess. There are a lot of good people trying to sort out who can do what and who is responsible for what, as well as how to keep things safe. A great place to learn more on the subject is the Sun User Group's annual "Computers & The Law" symposium. This year's symposium will be held in Tampa, Florida from November 12-15. For more information, contact the Sun User Group at 617-232-0514, or office@sug.org.
There are almost as many privacy organizations and resources as there are ones for security. Here's a sampling, but by no means all.
More information is contained in the privacy resources.faq. This FAQ, which is published by the Electronic Privacy Information Center (EPIC), is available on the Web from http://epic.digicash.com/epic and also available via anonymous FTP from cpsr.org in the /cpsr/privacy/epic/ directory. EPIC was established to focus public attention on the Clipper Chip, the Digital Telephony proposal, medical records privacy and the sale of consumer data, and other emerging privacy issues. For more info, e-mail: info@epic.org, or http://epic.digicash.com /epic or write to EPIC, 666 Penn. Ave, SE, Suite 301, Washington, D.C. 20003. Phone is 202-544-9240. The director is Marc Rotenberg.
Privacy Organizations
Cypherpunks - informal group that develops technological solutions to protect privacy. The Cypherpunks write cryptography and other programs, set up anonymous remailers and discuss political and technical issues. Meetings are regularly held in California and other states. E-mail: majordomo@toad.com, subscribe to cypherpunks ftp: ftp.csua.berkeley.edu.
Electronic Frontier Foundation - Formed in 1990, the EFF is possibly the largest of the privacy organizations. It maintains an Internet site, publishes an electronic newsletter, lobbies in Washington and also has an active chapter in Austin, Texas, home of the famed Steve Jackson Games case. E-mail: info@eff.org or http://www.eff.org Write to 1667 K St. NW, Suite 801, Washington, D.C. 20006-1605 or call 202-347-5400. The director is Andrew Taubman.
Internet Society - A group dedicated to fostering evolution of the Internet and its use. It sponsors a yearly conference, publishes a quarterly newsletter and works with standards committees to develop Internet standards for networking and privacy. E-mail: isoc@isoc.org or http://info.isoc.org/ Write to 12020 Sunrise Valley Drive, Suite 270, Reston, VA 22091 or call 703-648-9888. The executive director is Anthony Rutkowski.
Privacy Rights Clearinghouse. This is a California-based organization formed in 1992. The Clearinghouse has produced many fact sheets and an annual report, and maintains a toll free hotline to provide advice to consumers about their rights. E-mail: prc@teetot.acusd.edu or http: //www.manymedia.com/prc/ Write to 5998 Alcala Park, San Diego, CA 92110 or call 619-260-4806 or 800-773-7748 (in Calif. only). The director is Beth Givens.
U.S. Privacy Council - This is a coalition of U.S. privacy groups and individuals founded in 1991 to deal with privacy issues in the United States. The USPC works in Washington monitoring legislation and the activities of government agencies. The USPC works closely with other groups on privacy issues including National ID cards, reforming credit reporting, Caller ID and international issues. E-mail: privtime@access.digex.net. Write to P.O. Box 15060, Washington, D.C. 20003 or call 202-829-3660. The chairman is Evan Hendricks.
Online resources
There are a large number of electronic newsgroups and mailing lists dedicated to any and all aspects of electronic privacy. As a rule, the unmoderated ones tend to be higher traffic and lower content. Unmoderated newsgroups include: Alt.privacy, Alt.privacy clipper, Comp.org.cpsr.talk, Comp.org.eff.talk, Sci.crypt, talk.politics.crypto. There is also an unmoderated cypherpunks mailing list that discusses cryptography and technical protections of privacy. Be careful - it's high traffic, with more than a hundred messages a day. You can subscribe to the list by sending e-mail to majordomo@toad.com
Here are some of the many electronic newsletters and digests that are available:
EPIC Alert - A biweekly electronic newsletter of the Electronic Privacy Information Center. Mail to listserv@cpsr.org. First line: subscribe cpsr-announce. Back issues at cpsr.org /cpsr/alert and http://www.epic.digicash.com/
Risks Digest - Moderated digest on risks to the public using computers and related systems. Newsgroup: comp.risk. Also available as mailing list from e-mail: risks-request@csl.sri.com First line: SUBSCRIBE. Back issues at ftp unix.sri.com /risks. Moderator: Peter Neumann.
PRIVACY Forum - Moderated digest on privacy sponsored in part by ACM. For information, send message text: help to "privacy-request@vortex.com". Back issues and other related materials via FTP at ftp.vortex.com in "/privacy", by gopher at gopher.vortex.com or via WWW at http://www.vortex.com/ Moderator: Lauren Weinstein.
Lastly, most of the above organizations maintain an online presence, or the mailing lists and newsgroups are archived somewhere. Here's where: